I am trying to parse ESRI shapefiles that describe FAA TFRs. But they
are in NAD83 projections, with accompanying .prj files that look like
this:

PROJCS["North_America_Lambert_Conformal_Conic",
GEOGCS["GCS_North_American_1983",
DATUM["D_North_American_1983",SPHEROID["GRS_1980",
6378137.0,298.257222101]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic"],
PARAMETER["False_Easting",0.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",-93.13333333333335],
PARAMETER["Standard_Parallel_1",47.41333914430852],
PARAMETER["Standard_Parallel_2",47.43554955001912],
PARAMETER["Latitude_Of_Origin",40.0],UNIT["Meter",1.0]
]

A partial text dump of the corresponding .shp file looks like this:

Shape:8 (Polygon) nVertices=37, nParts=1
Bounds:(-3703.999933,823435.273920, 0, 0)
to ( 3703.999933,830843.274058, 0, 0)
( 0.00000000,830843.27405814, 0, 0) Ring
(643.19289130,830787.00193647, 0, 0)
(1266.84264658,830619.89536055, 0, 0)
(1852.00012149,830347.03211620, 0, 0)
(2380.88541892,829976.70258255, 0, 0)
...

I have not been able to figure out how to use .prj parameters to
transform the coordinates in the shapefiles to WGS84 (lat/lon) format.
Seems to me it should be a rather simple formula. Anyone out there
familiar with this problem?

-ted/2NO

Hi Ted,
NIMA makes a freely available coordinate translator to do exactly what
you are talking about. It's called GEOTRANS and they even release the
source. It is available here:
http://earth-info.nima.mil/GandG/geotrans/

-Mark

On Nov 17, 4:45*pm, Tuno > wrote:
> I am trying to parse ESRI shapefiles that describe FAA TFRs. But they
> are in NAD83 projections, with accompanying .prj files that look like
> this:
>
> PROJCS["North_America_Lambert_Conformal_Conic",
> * *GEOGCS["GCS_North_American_1983",
> * * * DATUM["D_North_American_1983",SPHEROID["GRS_1980",
> 6378137.0,298.257222101]],
> * *PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
> * *PROJECTION["Lambert_Conformal_Conic"],
> * * * PARAMETER["False_Easting",0.0],
> * * * PARAMETER["False_Northing",0.0],
> * * * PARAMETER["Central_Meridian",-93.13333333333335],
> * * * PARAMETER["Standard_Parallel_1",47.41333914430852],
> * * * PARAMETER["Standard_Parallel_2",47.43554955001912],
> * * * PARAMETER["Latitude_Of_Origin",40.0],UNIT["Meter",1.0]
> ]
>
> A partial text dump of the corresponding .shp file looks like this:
>
> Shape:8 (Polygon) *nVertices=37, nParts=1
> * Bounds:(-3703.999933,823435.273920, 0, 0)
> * * * to ( 3703.999933,830843.274058, 0, 0)
> * * *( *0.00000000,830843.27405814, 0, 0) Ring
> * * *(643.19289130,830787.00193647, 0, 0)
> * * *(1266.84264658,830619.89536055, 0, 0)
> * * *(1852.00012149,830347.03211620, 0, 0)
> * * *(2380.88541892,829976.70258255, 0, 0)
> * * *...
>
> I have not been able to figure out how to use .prj parameters to
> transform the coordinates in the shapefiles to WGS84 (lat/lon) format.
> Seems to me it should be a rather simple formula. Anyone out there
> familiar with this problem?
>
> -ted/2NO

At 23:45 17 November 2008, Tuno wrote:
>I am trying to parse ESRI shapefiles that describe FAA TFRs. But they
>are in NAD83 projections, with accompanying .prj files that look like
>this:
>
>PROJCS["North_America_Lambert_Conformal_Conic",
> GEOGCS["GCS_North_American_1983",
> DATUM["D_North_American_1983",SPHEROID["GRS_1980",
>6378137.0,298.257222101]],
> PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
> PROJECTION["Lambert_Conformal_Conic"],
> PARAMETER["False_Easting",0.0],
> PARAMETER["False_Northing",0.0],
> PARAMETER["Central_Meridian",-93.13333333333335],
> PARAMETER["Standard_Parallel_1",47.41333914430852],
> PARAMETER["Standard_Parallel_2",47.43554955001912],
> PARAMETER["Latitude_Of_Origin",40.0],UNIT["Meter",1.0]
>]
>
>A partial text dump of the corresponding .shp file looks like this:
>
>Shape:8 (Polygon) nVertices=37, nParts=1
> Bounds:(-3703.999933,823435.273920, 0, 0)
> to ( 3703.999933,830843.274058, 0, 0)
> ( 0.00000000,830843.27405814, 0, 0) Ring
> (643.19289130,830787.00193647, 0, 0)
> (1266.84264658,830619.89536055, 0, 0)
> (1852.00012149,830347.03211620, 0, 0)
> (2380.88541892,829976.70258255, 0, 0)
> ...
>
>I have not been able to figure out how to use .prj parameters to
>transform the coordinates in the shapefiles to WGS84 (lat/lon) format.
>Seems to me it should be a rather simple formula. Anyone out there
>familiar with this problem?
>
>-ted/2NO
>I'm no guru, I don't know the inner workings of the shapefile format,
but I think I can be of some help. It appears to me that your data is in
datum NAD83, projected in Lambert Conformal Conic. I'm guessing that
converting from LCC to WGS84 is not a simple formula. The question is,
what do you actually want done? Converting a list of points like
waypoints or track log from LCC to WGS84 is easy, converting airspace
features and outputting as a coordinate list is another. (Maybe it is
easy and I just don't know how and someone else can fill you in) But I
recommend converting formats of entire files or parts of files using
conventional instruments like MapWindow, a free and quite capable GIS
program. Among other things, it can buffer (add rings at selected
distances) points, maybe that is all you need to do with that TFR file...
With a $25 added application it will convert text file coordinates to
google earth files too! That and the "GPS Converter" page people have
mentioned here before gets my data from anything to just about anything
else.

http://www.gpsvisualizer.com/convert_input

Global Mapper for $200 is the do it all converter. I have it too but I
use MapWindow most of the time. If it's just a one time conversion and
you have a specific output format, you could send me the data I can
convert it for you.

Mark, I've looked at GEOTRANS before, but it's packaged primarily as a
GUI application, which doesn't help me. My processing will be done on
a Linux server.

GEOTRANS comes with source, but I haven't yet found the piece that
does the transformation I'm looking for. Still looking though.

-ted

Thanks Jim but that doesn't help either ... anything interactive (GUI
or otherwise) doesn't help; I need source code that I can compile in
Linux and Windows (cygwin) environments...

Hi;
It is built & packaged for UNIX as well, see:
http://earth-info.nima.mil/GandG/geotrans/#Downloading

If that is no good, contact (GEOTRANS Project Managers) Brian Akers (St.
Louis) and Dan Mullaney (Bethesda).

In the final instant I might hve time to find the relevant functions but
please try to investigate yourself.


Thanks,

Jonathan




"Tuno" > wrote in message
...
> Mark, I've looked at GEOTRANS before, but it's packaged primarily as a
> GUI application, which doesn't help me. My processing will be done on
> a Linux server.
>
> GEOTRANS comes with source, but I haven't yet found the piece that
> does the transformation I'm looking for. Still looking though.
>
> -ted

For the morbidly curious ... and with thanks also to those who
responded by e-mail ...

I found the answer to my question in a program available for both
Windows and Linux by Gerald Evenden at the Woods Hole office of the
Dept of the Interior, called "proj" (Cartographic Projection
Procedures).

The shapefile's .prj parameters indicate a geographic-to-geodetic
Lambert Comforal Conic projection. Providing those parameters to the
"proj" program with a request for inverse projection, along with all
of the cartesian coordinates in the shapefile, yields the geocentric
(lat/lon) coordinates.

Armed with this weapon I can parse FAA TFRs (and state borders and
anything else) into Special Use Airspace files.

And thanks to Lynn Alley I also now know how to download a single .zip
file with all of the TFRs already in geocentric format. Thanks 2KA!
Not yet sure how useful it will be, but coming up soon, TFR airspace
files.

-ted/2NO

On Nov 19, 11:13*pm, Tuno > wrote:
> Not yet sure how useful it will be, but coming up soon, TFR airspace
> files.

TFRs are usually so short lived that it's unlikely anyone would have
have current files loaded.

What I think would be more useful for Arizona pilots is a depiction of
the arrival and departure routes for KPHX and KTUS. Being close to
cloudbase on a busy arrival route is unwise but how many pilots know
where they are?

Andy

On Nov 20, 8:14*am, Andy > wrote:
> On Nov 19, 11:13*pm, Tuno > wrote:
>
> > Not yet sure how useful it will be, but coming up soon, TFR airspace
> > files.
>
> TFRs are usually so short lived that it's unlikely anyone would have
> have current files loaded.
>
> What I think would be more useful for Arizona pilots is a depiction of
> the arrival and departure routes for KPHX and KTUS. *Being close to
> cloudbase on a busy arrival route is unwise but how many pilots know
> where they are?
>
> Andy

I disagree with you on TFRs (but the comments on approach/departure/
STAR etc. are right on. Those folks we might run into (we are likely
to get the blame) just don't operate in our VFR world and we need to
think how they think and where they will be).

Given the danger (read mostly FAA enforcement danger) of violating a
TFR and how little work it would be to load a file into a PDA I don't
see the problem. Most TFRs (presidential, fire, etc.) are well known
about the morning of a flight. Sure others might pop-up, but you'll
get most this way.

I published airspace files for Californian fire related TFRs (some
that lasted weeks) for pilots flying out of Williams during summer.
Sure at times you should not be anywhere near an active fire TFR, at
other times there are large TFR areas with little activity and no
smoke/visibility hazards. It literally is only a few clicks to synch
such a file to a PDA. In very busy airspace/new TFR risk areas I'll
bring along my Garmin 496 with XM weather and TFR alerts - it's helped
with pop-up TFRs, and allowed me to radio other gliders to warn them.

I subscribe to Ted's Just Soar airspace service and really appreciate
what he is doing.

Darryl

> TFRs are usually so short lived that it's unlikely anyone would have
> have current files loaded.

I'm thinking more about contest situations. At Parowan this year we
had TFRs in the task area most days. Having the PDA programmed to
always load "dailytfrs.sua", even if the file is empty, would make for
an easy daily procedure.

The feature will be online before the next season starts. No
subscription necessary; the server will auto-generate the SUA file
each morning and pilots would just copy a fixed URL (e.g.
http://www.justsoar.com/tfr/dailytfrs.sua) to their PDA.

Advance thanks to Lynn Alley "2KA" for pointing me to the web resource
with all the TFR shapefiles in one zip, and the tip on how to use wget
to get it.

~ted/2NO

Tuno wrote:
>> TFRs are usually so short lived that it's unlikely anyone would have
>> have current files loaded.
>
> I'm thinking more about contest situations. At Parowan this year we
> had TFRs in the task area most days. Having the PDA programmed to
> always load "dailytfrs.sua", even if the file is empty, would make for
> an easy daily procedure.

I'll like that feature during our fire season, when we might have 10 or
more fire TFRs within reach (WA, OR, ID) in a bad year.


--
Eric Greenwell - Washington State, USA
* Change "netto" to "net" to email me directly

* Updated! "Transponders in Sailplanes" http://tinyurl.com/y739x4
* New Jan '08 - sections on Mode S, TPAS, ADS-B, Flarm, more

* "A Guide to Self-launching Sailplane Operation" at www.motorglider.org

I use a Garmin 396 with XM weather. It's $50 a month for the weather
service. Displays TFR's, and all manner of weather data including lightning
strikes and winds aloft.

bumper


"Eric Greenwell" > wrote in message
...
> Tuno wrote:
>>> TFRs are usually so short lived that it's unlikely anyone would have
>>> have current files loaded.
>>
>> I'm thinking more about contest situations. At Parowan this year we
>> had TFRs in the task area most days. Having the PDA programmed to
>> always load "dailytfrs.sua", even if the file is empty, would make for
>> an easy daily procedure.
>
> I'll like that feature during our fire season, when we might have 10 or
> more fire TFRs within reach (WA, OR, ID) in a bad year.
>
>
> --
> Eric Greenwell - Washington State, USA
> * Change "netto" to "net" to email me directly
>
> * Updated! "Transponders in Sailplanes" http://tinyurl.com/y739x4
> * New Jan '08 - sections on Mode S, TPAS, ADS-B, Flarm, more
>
> * "A Guide to Self-launching Sailplane Operation" at www.motorglider.org